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n exploratory design is by no means complete. It is a rough con¬ 
ceptual sketch of the key objects of a design, what their roles are, 
and a partial list of their responsibilities and collaborations. A lot 
ot detail needs to be added before this relatively high-level design 
description can be turned into code. I want to focus on just one of 
those details: how to turn an imprecise list of collaborations into a more rigorous 
design description and finally into Smalltalk code—a relatively straightforward 
process that can be tackled systematically, following a few general principles 
during this translation process results in classes that are more reusable and easier 
to change or enhance. 

Turning an architectural drawing into a detailed set of blueprints shares a few 
similarities with the software construction process. When developing detailed 
blueprints, an architect translates a rough architectural drawing into a specific list 
of materials to be used and a fairly explicit map of how those materials should be 
composed in the finished product. This still leaves a lot of latitude for decision¬ 
making and creativity during construction—just ask anyone who has had a house 
built. You don’t start construction expecting a barn and end up with a skyscraper! 
The same principles apply to constructing software. 

Before turning an object-oriented design description into a detailed set of 
software blueprints, you must consider the tools and environment you will use 
during construction. Mapping an object-oriented design into Smalltalk code re¬ 
quires matching up object-oriented design concepts with the appropriate 
Smalltalk language and programming constructs. It’s essential when constructing 
a solution to have a good understanding of pre-existing components. Architects 
don't invent new kinds ot fasteners or building material lor each construction 
project. Similarly, proficient Smalltalk programmers know their Smalltalk class li¬ 
braries. They don't construct a new class when a readily available one will do the 
job, even if it isn’t perfect. 

Before systematically adding more rigor to our collaborations, let’s examine 
our Smalltalk construction environment. How many different ways are there in 
Smalltalk for one object to have visibility of another? Objects can’t collaborate 
unless they can send each other messages. The client, or sender of a message, first 
needs to have visibility of the server or receiver of the message. Message sending 
is all done within the context of a method. Anyone with a modest amount of 
Smalltalk programming experience should be able to come up with most of these 
techniques fairly quickly, for new Smalltalkers this is a good exercise in funda¬ 
mental implementation constructs. You will use these constructs (and other 
techniques) when you translate designs into executable program code. 

Here are some ways an object may he visible within a method: 

■ an object always has visibility of itself (sending messages to self is fundamental 

to Smalltalk programming) 


continued on pt\$c I 










John Pugh Paul White 


EDITORS’ 

CORNER 


S ince many of you will be reading this while attending OOPSLA’92 in Vancouver, we 
thought it appropriate to take stock of the impact OOPSLA has had on the growth of 
Smalltalk and vice versa. As we mentioned in our editorial last year following OOPSLA, 
we were struck by Smalltalk’s "emergence” as an industrial-strength vehicle for large-scale 
object-oriented system development. Looking back, it's probably fair to say that was a 
new role for most of us. For the first time, it seemed we did not have to constantly defend 
the decision to use Smalltalk. For the first time, we regularly heard the question, Why 
aren’t you using Smalltalk? 

Both of the major Smalltalk vendors have major plans for OOPSLA. Digitalk has re¬ 
cently released the OS/2 version of PARTS Workbench, their long-awaited parts assembly 
and reuse tool set technology. Will this product lead us closer to the promised land of ap¬ 
plication construction from prefabricated software parts? ParcPlace will be showing Vi¬ 
sual/Works, their new application development environment for client-server, GUI-based 
applications. With a growing number of third-party vendors also showing Smalltalk-re¬ 
lated products, the OOPSLA exhibits floor will be an active place for Smalltalkers. Watch 
for reviews of many of these products in upcoming issues of the Report. 

Once again, we feature Rebecca Wirfs-Brock’s design column in the Report. This 
month, Rebecca describes the different ways one object can be visible to another and sug¬ 
gests guidelines for managing this visibility. In the long run, she suggests, it is vital for 
"teams to develop and stick to a style guide that addresses when and how to use parti'- 
Smalltalk constructs.” Having faced these issues many times before on projects, we can 
only add that we agree wholeheartedly. 

Also in this issue, Kent Beck introduces us to a number of collection idioms, illustrat¬ 
ing how best to use Smalltalk’s collection class library, which has traditionally been one of 
Smalltalk’s best-selling features. Greg Hendley and Eric Smith return to their pro¬ 
posal for a three-layered architecture for building GUIs using a more complex example to 
highlight many of the pitfalls normally encountered during GUI development. Alan 
Knight rolls up his sleeves in this month’s Best of comp.lang.smalltalk column and covers 
a number of very specific and technical questions relating to the implementation of 
Smalltalk. As he points out, many of the discussions he covers this month offer “only an 
understanding of the source of the problems” rather than solutions. Finally, Jan Steinman 
and Barbara Yates review ENVY Developer by Object Technology International. In our 
ongoing coverage of team programming tools, Jan and Barbara describe ENVY’s philoso¬ 
phy and put ENVY’s features into perspective with respect to the many other tools cur¬ 
rently on the market. 

If you are attending OOPSLA, why not take a few minutes to drop by and talk with us? 
It is always useful to find out what kind of things you’re interested in and how you’re us¬ 
ing Smalltalk. See you there! 
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10 \ears Ago, 



When OTI Suggested 
That Object-Oriented 
Technology Would 
Revolutionize 
The Software Industry, 
People Called Us 
Crazy... 


Now, They Simply Call Us 


For over 10 years, OTI has been on the 
leading edge of object-oriented software 
engineering. And today, as more and more 
companies adopt this exciting, new 
technology, OTI remains the leader in 
providing industrial and commercial 
object-oriented solutions. 

Partners in 

Object-Oriented Development 
OTI’s unique technology alliance program 
provides a means of accelerating product 
development and introducing new software 
technology. OTI’s technology is being used 
in products ranging from pen computers to 
real-time systems. Through these alliances, 
we’ve earned a solid reputation for developing 
high-quality, reliable software - on-time, 
within budget and to demanding product 
specifications. This success is attributed to 


OTI’s ENVY-i Developer - the first multi-user 
development environment for object-oriented 
engineering. 

OTPs ENVY /Developer - Product 
Development Tools For Smalltalk 
With ENVY /Developer, large and small 
software engineering teams work within an 
interactive, shared programming environment. 
Inside this environment, team members share 
common development tools, common software 
components and common source code - that 
means faster cycle times, increased productivity, 
virtually no duplicated code, and no wasted 
effort. 

Applications are created efficiently and 
effectively, from beginning to end. Using 
ENVY /Developer, the team passes the 
application through each phase of the software 


manufacturing lifecycle - conceptualizing, 
prototyping, manufacturing, testing, release 
and maintenance - without ever leaving the 
environment. ENVY I Developer also tracks 
this process by providing complete software 
version control and multi-platform 
configuration management. 

Interested? 

If your organization is interested in joint 
research and development or you would like 
more information on ENVY /Developer and 
object-oriented programming environments, 
call us today. 

Object Technology 
International Inc. 

Engineering Ideas 
Into Products 



Canada Telephone: 613-820-1200 • Fax: 613-820-1202 • E-mail: in1o@oti.on.ca USA Telephone: 602-222-9519 • Fax: 602-222-8503 
ENVY is a registered trademark of Object Technology International Inc. 



Object VISIBILITY continued from page 1 

■ those objects passed in as arguments 

■ an object’s class (by sending the message self class) 

• values of instance variables—objects that are part of the ob¬ 
ject’s encapsulated state 

■ any object returned as a result of sending a message to an 
object already visible 

■ objects assigned to temporaries 

• any class whose name is known 

• you can create an object whenever you need it (assuming 
you know the name of its class) 

• an object that is a value of a global variable (for example, 
Smalltalk) 

■ class variables of the object’s class or any of its superclasses 

• variables in pools specified by the object’s class 

• constant objects known to the language (e.g., nil, true, and 
false) 

■ literals (including integers and floating point objects, 
strings, literal arrays, a literal block) 

Enough! I asked my colleagues for additions and got several 
that were far too obscure to include in this column. Let’s orga¬ 
nize these objects into four categories: 

1. Globals of varying scope. We can include globals, pools and 
pool variables, and even class variables in this category. 
These global spaces typically contain objects visible to many 
other objects. If you can name an object in one of these 
global spaces, it’s yours for the accessing. 

2. Objects that dynamically become known within the context of 
a method. These include objects passed in as arguments and 
any object returned from a message. An object that be¬ 
comes visible in this way can always be retained for later 
reference or discarded as needed. 

3. Objects that are part of an object’s encapsulated state, i.e., in¬ 
stance variables. 

4. Basic programming constructs. It's difficult to write any 
significant code without using nil, true, or false. Literals also 
fall into this category and are just as ubiquitous. 

EXAMINING THE EXPLORATORY DESIGN 

Most collaborations are recorded between objects at the same 
or next layer of detail. If a designer has figured out the details 
of an algorithm, quite a number of collaborators at very differ¬ 
ent conceptual levels may be listed. This is an exception rather 
than the rule; it is more common to have a vague idea that 
some kind of collaborative effort is required. Most often col¬ 
laborators are a list of objects that will become known dynami¬ 
cally, not those that are permanently visible. 


Lists of collaborators certainly aren’t exhaustive or very pre¬ 
cise. But this doesn’t mean we have a bad design, just a prelim¬ 
inary one. During the early design stages, we determine when 
to use the services of some key collaborators; we don’t yet need 
to determine precisely how we will use them. First, we develop 
a model of what an object should do along with a vague idea of 
some of its key collaborators. Next, we need to try out a num¬ 
ber of alternatives. 

To add precision, we need to determine whether an on¬ 
going dialog will be required or whether a single message 
will do. We need to construct a model of how each respon¬ 
sibility will be accomplished. This requires experimenta¬ 
tion, since there’s no one right way to decompose a solu¬ 
tion. However, when working out these details, there are a 
number of principles worth following to make your imple¬ 
mentation cleaner. 

LIMIT VISIBILITY 

One guiding principle is to make objects visible to each other 
on a need-to-know basis. An even stronger statement; Don’t 
retain visibility of any object if you absolutely don’t have to. In 
general, design objects so they know as few other objects for as 
short a time as possible. If an object only needs to know about 
another for the duration of a method, pass it in as an argument 
and let the client supply necessary information. Carrying this 
to extremes, however, will result in objects with poorly de¬ 
signed interfaces. 

SIMPLIFY COLLABORATION SEQUENCES 

Complex message protocols that have lots of arguments or re¬ 
quire exacting sequences of messages between client and 
server make objects difficult to use and understand. A balance 
must be achieved between exposing too much complexity and 
giving enough controls to the client. Simple interfaces are 
worth striving for. 

For example, I prefer to drive a car with a manual trans¬ 
mission because of the extra control I have, while my mother 
has driven an automatic car for years. She switched from 
manual when automatic transmissions became popular be¬ 
cause she preferred the simplicity. It certainly is much easier 
to accelerate a car by sending the single message rayCar acceler¬ 
ate. I go through this sequence whenever I need to shift gears 
before accelerating; 

myCai depressClutch 
myCai shiftGeai: a GeaiValue 
myCar releaseClutch 
myCai accelerate. 

Most people prefer a simpler interface, provided the neces¬ 
sary services are offered. Too many software engineers offer a 
manual transmission when their clients prefer the simpler 
driving method. 

continued on page 11 
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Jan Steinman and Barbara Yates 


Object Technology's 
ENVY Developer 


THE PROBLEM 

Since the mid-1970s Smalltalk has been the development envi¬ 
ronment by which all others are measured. The simple, rapid 
hypertext-like browsing of code combined with incremental 
compilation raise programming expectations to the level of 
instant gratification. 

Smalltalk gained a reputation as a toy, not because it lacked 
power or expressiveness, but because few large systems were 
written in it. Although it was certainly possible to do big pro¬ 
jects in Smalltalk (Smalltalk itself being the best example), 
most of its work reached a certain critical mass then stopped— 
roughly at the limit of what one person could manage. The ul¬ 
timate individual software development environment was just 
that: an individual environment. 

A big part of Smalltalk’s instant gratification is the way it 
manages change. Each time you save a method, its source code 
is recorded in a file and can be retrieved if necessary. This works 
fine for individual developers, but is unmanageable for teams. 

At Tektronix Laboratories we realized that the lack of team 
facilities was holding Smalltalk back. Tek wanted to reap the 
object-oriented benefits of Smalltalk on larger projects, so we 
developed different team programming environments for use 
within the company. These “groupware” environments fell 
into two general categories: those that maintained the basic 
Smalltalk “what you saved is what you get” philosophy, and 
those that followed the C/UNIX “check-in, check-out” philos¬ 
ophy. Beyond this philosophical split, they all attempted to ad¬ 
dress a common set of basic groupware needs. 

NEEDS 

We've studied and worked on the groupware problem at Tek¬ 
tronix and as consultants. Through interviews with users and 
their managers, literature research, and personal experience 
implementing and using many groupware tools, we came up 
with a basic set of requirements for Smalltalk team program¬ 
ming, roughly prioritized by importance: 

■ Integration. Groupware must support the combining of 
code received from different developers, which is primarily a 
function of detecting conflicts and managing dependencies. 

■ Code sharing and concurrency control. A developer must 
be able to work on a code module without undue concern 
that other developers are also modifying the same module. 


■ Revision history. Different versions of code need to be 
maintained so that if new versions are found to have prob¬ 
lems, old ones can be easily retrieved. 

■ Configuration management. Different combinations of 
code modules need to be assemblable; previous versions of 
configurations are necessary for regression testing. 

■ Documentation. In addition to standard Smalltalk method 
and class comments, the new components necessary to 
groupware require documentation support. 

■ Branching and merging. It is sometimes necessary to di¬ 
verge from a single development path; then the two paths 
usually must be brought back together. 

Aside from these basic needs, a number of specialized needs 
are often provided by groupware environments, including per¬ 
formance monitoring and tuning tools, object storage mecha¬ 
nisms, and facilities for generating link libraries. We’ll examine 
how Object Technology International’s (OTI) ENVY/Devel- 
oper, referred to here simply as “Envy,” meets these needs. 

ENVY PHILOSOPHY 

It is apparent that Envy was designed, and not simply cobbled 
together. 

Envy adheres fairly well to the philosophy that “few 
concepts, rigorously applied” are better than special cases 
for everything. Although it has a complicated user interface, 
and does take some learning, most users find it predictable 
and easy to understand once they have absorbed the central 
concepts. 

Envy maintains the original “what you saved is what you 
get” paradigm, rather than succumbing to the easier-to-imple- 
ment “check-in, check-out” pattern, and uses the Smalltalk 
method as the smallest unit of code sharing. This means that 
team members can instantly view each other’s work, fostering 
communication and avoiding needless branching. 

Envy is conservatively designed to avoid accidents. It uses 
error avoidance rather than error detection. If an operation 
does not make sense in the current state, its menu selection is 
disabled. Sometimes this can be frustrating, but we’re con¬ 
vinced it is much better than picking up the pieces after inad¬ 
vertently selecting a “you asked for it, you got it” operation. As 
a corollary to error avoidance, Envy uses multiple browsers to 
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let you examine the present state of the system rather than rely 
on multiple reports to tell you what happened after a problem. 

Large-scale design is fostered by partitioning the problem 
into functional units. In fact, Envy’s base image comes pre¬ 
partitioned into functional units, making it easier, for instance, 
to substitute a completely different user interface. 

Class ownership has been debated in this and other publica¬ 
tions. Envy is subtly different. It insists upon class definition 
ownership: Any number of developers can provide methods 
that extend a class, but only one developer is allowed to change 
a class’s structure. Other groupware systems eschewing class 
ownership can result in many conflicting definitions for a class, 
which is deadly to large projects! 

Finally, Envy obeys Einstein’s dictate that “everything 
should be made as simple as possible, but no simpler.” Where 
it makes sense to override a concept with a special case, Envy 
does so. 

ENVY CONCEPTS 

Envy works from these basic concepts: 

■ All source code resides in a shared repository. 

• There is a hierarchy of software components that have con¬ 
tainer relationships to each other. 

■ Loading and unloading a component is atomic. 

■ Software components progress through stages, from edition 
to version to release. 

■ Work in progress is carried out in mutable editions of 
components. 

■ Components become immutable when declared versions. 

■ Users are associated with components in specific roles, 
which may or may not be enforced. 


Shared repository 

All source code resides in a shared repository, which accepts 
changes and makes them immediately shareable. Instead of the 
typical sources and changes files, images are connected to a 
shared network repository. As soon as a change to source code 
is saved, the new code is appended to the repository. Since all 
the team members are connected to the same repository, code 
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changes are immediately accessible to other members of the 
team, who can view or load the new code into their image as 
desired. Both the source strings and the compiled bytecodes 
are stored in the repository; loading compiled code from the 
repository is five to ten times faster than file-in. 

Hierarchy of software components 

There is a hierarchy of software components that have con¬ 
tainer relationships to each other. These components are 
methods, classes, subapplications, applications, and configura¬ 
tion maps. The smallest component is the method, which is al¬ 
ways a part of a class or class extension. Methods have version 
history, as do all other components. 

Classes differ from class extensions in that classes include the 
class definition and class comment, while class extensions in¬ 
clude only methods. Classes and class extensions are contained 
by applications or subapplications. As mentioned earlier, class 
extensions provide for multiple owners of bits and pieces of a 
class. We use the term class to mean either class or class exten¬ 
sion, unless a distinction is needed. 

An application is a collection of classes that together serve a 
useful purpose. Applications declare prerequisites, which are 
other applications required to be present so they can function. 
Loading an application loads its contained classes and their 
contained methods (Figure 1). 

Applications are actual Smalltalk classes and, as such, they 
can implement behavior. For example, when an application is 
loaded into an image, it is sent the message loaded. The devel¬ 
oper puts into the loaded method any needed initializations 
that should occur when the classes in the application are 
loaded, such as initializing pool dictionaries. Another behavior 
of applications is that they can respond to some standard sys¬ 
tem events, such as image start up and shut down, by imple¬ 
menting the methods startup and shutDown. Objectworks 
Smalltalk has a similar function via dependents, but since it is 
implemented using a dictionary, the order of events is nonde- 
terministic. In Envy, system event messages are sent in prereq¬ 
uisite order, so applications can respond to the events in a pre¬ 
dictable sequence. 

Subapplications are applications with some restrictions 
placed on them. They are always contained in and loaded as 
part of an application; they cannot be loaded by themselves. 
Subapplications have two typical uses: to isolate platform de¬ 
pendencies and to organize classes within a large application. 
When an application is loaded, the loading of each subapplica¬ 
tion is controlled by a boolean configuration expression; that is 
how a platform-specific subapplication is loaded appropriately. 
We use the term application to mean either application or sub¬ 
application, unless stated otherwise. 

Configuration maps are named collections of applications. 
Most teams will use a configuration map to periodically rebuild 
their image, bringing in the latest integrated and tested versions 
of all their applications. Another use of configuration maps is a 
“one button” way to load an application and all of its prerequi¬ 
sites. In a large organization that promotes firm-wide compo- 


6 


The Smalltalk Report 




s / 


Now available! 
silence 2.0 
for Windows 
and PM 


cd 


/ 


CD 


CD 


n 


CD 


CD 


o 



o 


Multi-user source code control 
and versioning system 
for Smalltalk/V 


id 


NEW! code managed Dn a dienl-seivpr model ■ 
NEW! aulomc;lie background updating ■ 
NEW! linked sub-projetl support ■ 
NEW! UFO per si si en I object loolkil ■ 
NEW! flulomalic report genera lion ■ 
nulomalic change documenting ■ 
ship compiled code without source ■ 
package ond lock releases ■ 
change lag browser and restorer ■ 

Starting from 

$ 149.95 

source code included 


igamma solutions 

® IJniI 6, 387 Spadina Avenue, Toronto, Ontario, Canada, M5T 2G6 Phone: (416) 351-8833 Fax: (416) 400-2850 CompuServe 75430,400 


Shi:ipii 


lie c '! S 00 i 

17 r,s. : . 


nil- 


'2 ■» 00 ronrici n si ill' No» th Ameim S7S00 mail, cel' In reieiei prscr- oiil ; i:!i' No* ill Anericn. Visa aidei c odd S M0 AMEX OR MASIERCAKU. 
tin oidnic add PS.I silence i a dailemnrk of d'gcnvnn -nlulionv Smnlllalk-'V i‘. rj irgi'.lpid Imdemaik of Digilcilk, hie. 


nent reuse, configuration maps are used to load all the firm- 
specific versions of base applications, such as those containing 
Object, String, etc. Other configuration maps are centrally man¬ 
aged to load the latest versions of the firm’s reusable compo¬ 
nents. Each project team may then have its own configuration 
map to load its applications on top of the firm’s customized 
base, plus whatever reusable components the team needs. 

Atomic loads 

Loading and unloading a component is atomic. Envy performs 
“loadability” tests before beginning the load of a component 
and notifies you of the first error it finds (if any). The image is 
never left in an inconsistent state—loading either succeeds 
completely or fails completely. This is especially important in 
big components, subapplications and larger. 

A totally foreign concept to Smalltalk users is that of un¬ 
loading. Any component that has been loaded can be un¬ 
loaded. Until Envy, a developer typically unloaded unwanted 
code by ditching the image and file in everything except the 
unloaded code! 

Component stages 

Software components progress through stages, from edition to 
version to release. Work in progress is carried out in mutable 
editions of components. Declaring an edition to be a version 
disables changes. A version is released to its containing compo¬ 
nent. All components make one or more passes through a 
change cycle between "first code” and completion. Any new 
component is an edition when it is created. Editions can be 
changed and are signified in the user interface with a times¬ 
tamp next to the component name. The developer works on 
the component until it has reached a stage that should be 


“frozen” (especially if it’s working and the developer wants to 
make some changes that could break it!). The developer then 
makes the component a version. 

Versions are identified by a label next to the component 
name, instead of the timestamp that denotes editions. Envy sug¬ 
gests version names, but the developer can specify an arbitrary 
string, such as “for testing 1.0.” Once a component has been ver¬ 
sioned, it and its label are frozen and cannot be changed. There¬ 
fore, before a component can be versioned, all its parts (and all 
their parts, recursively) must have been versioned. 

If developers wish to make changes to a version, they create 
a new edition of the component. If those changes destroy the 
component beyond all recognition, or if the developer simply 
wants to do regression testing, the old, unchangeable versions 
can be reloaded easily. 

At some point, the developers decide it is time to foist 
their creation on their peers. If they own the component, 
they can release it to its containing component, at which 
point those who load the containing component get the 
new part. 

To avoid unnecessary interference with the traditional 
Smalltalk programming style (as well as interference among 
team members), special rules apply to some components’ pro¬ 
gression through the change cycle: 

■ Methods are always editions and, if currently loaded, are 
implicitly released to their containing class. 

■ Changing a method in a class version automatically creates 
a new class edition. 

■ Classes must be versioned to be released to their containing 
application or subapplication. 

These exceptions allow you to use Envy transparently for at 
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least 95% of what a Smalltalk developer normally does, while 
keeping your “work in progress” from being accidentally 
propagated. 

User roles 

Envy users fill roles with respect to software components, own¬ 
ers, and developers; flexible access protection may restrict the 
roles an individual user may fill. The creator of any component 
automatically has the most authority. This user is called the 
owner or manager of the component, and can reassign this role 
to another user. The roles exist for one version and are carried 
over into new editions until they are reassigned. We use the term 
owner to mean either owner or manager, unless otherwise stated. 

Any number of developers may be assigned to a class. These 
developers make changes to the class in their own edition, 
which they alone can version. The class owner can then release 
the class to its containing application. 

Flexible permissions are associated with an application. Un¬ 
less the owner of an application explicidy changes it, anyone has 
permission to load applications, make new editions of classes, 
and view source code. This default allows development of a class 
to be a collaborative effort. If desired, application owners can re¬ 
strict these operations to either themselves or the assigned devel¬ 
opers. Private methods can be controlled separately from public 
methods, enforcing the “contract” interfaces between teams. 

Owners of applications and configurations are the only 
people who may version them. They also have other responsi¬ 
bilities, such as determining the prerequisites for an applica¬ 
tion or creating new editions. In the simplest case, common in 
many organizations, one person owns all the classes and man¬ 
ages the application. 

ENVY TOOLS 

Envy has a variety of browsers for different purposes. Usually 
the developer will use the Application Manager and one of the 
development browsers; the choice of browser depends on their 
preferred view of the “world” of their image. Many operations 
are available in more than one browser, so the developer is not 
forced to switch browsers to perform common tasks. 

The development browsers consist of two views of the im¬ 
age world: class-centered or application-centered, The Classes 
Browser arranges all classes in inheritance order and has a sec¬ 
ond pane that shows which applications define or extend the 
class. Italics indicate prototols that are not part of the selected 
application or applications. Many list panes throughout Envy 
allow multiple selection—doing this in the protocols pane 
shows the union of their lists in the methods pane. Also avail¬ 
able is a Class Browser for browsing a single class. 

The Applications Browser (and the single application Ap¬ 
plication Browser) presents the alternate, application-centered 
view. Selecting an application shows a list of all the classes it 
defines and extends, plus a toggle option to show all the pre¬ 
requisite classes. 

Some prefer the Classes Browser and others the Applications 
Browser. Smalltalk-80 users may find applications somewhat 
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Figure 2 : History of Object, showing differences between two editions. 

analogous to class categories and therefore prefer the Applica¬ 
tions Browser. Smalltalk/V users are often more at home with the 
alphabetical/hierarchical view presented by the Classes Browser. 

The Application Manager allows manipulation of the devel¬ 
opment stage of applications and classes. This browser lists all 
of the applications loaded in the image, with subapplications 
indented according to their nesting level. With one application 
selected, the other panes list the defined and extended classes, 
the application’s prerequisites, and the application owner and 
assigned developers. This browser is used for organization and 
management beyond normal code development, such as load¬ 
ing and unloading applications or classes, versioning applica¬ 
tions and classes, releasing classes, and determining the com¬ 
position of applications. 

Recreating an image in Envy is easy. Using the Configuration 
Maps Browser, simply load one or more configuration maps into 
the image supplied by OTI. Generally, teams define configura¬ 
tion maps that list the various applications comprising their “de¬ 
liverable.” All of the base image applications in the repository 
supplied by OTI are already listed in the supplied configuration 
map called Envy/Manager. Developers can examine existing 
maps in the repository, create new maps, and edit the contents of 
map editions. When all the applications in a configuration map 
are versioned and the map is loaded, a configuration map owner 
can version it. The map owner does not have to experiment with 
the load order of the applications in a map—the applications’ 
prerequisites determine the order and the entire load is atomic. 

A prime feature of Envy is the collection of tools for version 
history and comparison. In all the development browsers, it is 
possible to open a browser on all editions of a selected comp¬ 
onent. These history browsers list, in reverse chronological or¬ 
der, all the editions and versions of the component. From the 
editions list it is possible to load a selected edition or select any 
two editions and browse their differences in a Changes Browser. 
This browser displays differences by highlighting lines and al¬ 
lows loading of the alternate edition if desired (Figure 2). 

Sometimes there will be concurrent development of the 
same component by two (or more) developers. This happens 
at the class level because, unlike “check-in, check-out” systems, 
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there is no exclusive locking of a class to prevent others from 
making needed changes. This might occur at the application 
level when a production version of an application is undergo¬ 
ing maintenance while other developers are working on “the 
next release.” The same Changes Browsers that show you the 
differences between two editions also allow you to merge two 
editions by installing one or the other version of a method or 
definition, or by copying, pasting, and compiling a new devel¬ 
oper-merged edition of a method 

There are two buttons in development browsers worthy of 
special mention. The public/private toggle displays public or 
private classes (in the classes pane), or public or private meth¬ 
ods (in the methods pane). Private classes should not be refer¬ 
enced and cannot be subclassed outside of their applications. 
Subclassing of private classes is strictly enforced; referencing 
results in a warning. Private methods should not be called out¬ 
side of their inheritance hierarchy. The application owner can 
deny non-group members the ability to read the private code. 

If you don’t like the tools provided, keep in mind that Envy 
is an open system. Certain low-level code that accesses the 
database is hidden, not so much because OTI doesn’t want you 
finding out their secrets (determined Smalltalkers will find 
ways to view this code), but because changing these methods 
could damage the database. Custom user fields can be associ¬ 
ated with any Envy component if additional state is needed for 
some reason. If an organization needs custom capabilities, 
adding them to Envy is not much more difficult than adding 
them to Smalltalk. An added advantage is the many reusable 
classes that can be used royalty-free in your application. 

FEATURE COMPARISON 

Table 1 shows how some groupware environments compare in 
solving basic needs of the Smalltalk development team, along 
with the platforms supported by each. Not all are currently 
available; we listed those we know about to contrast different 
capabilities and demonstrate the growth in the genre. 

Ad hoc refers to individuals working in separate images, 
filing out bits of code. This is, unfortunately, how a lot of team 
Smalltalk is still written. 

Change set refers in general to techniques that exploit the 
Smalltalk-80 change set mechanism. Tektronix developed 
browser support for multiple change sets; Knowledge Systems 
Corporation later refined the concept and marketed change 
set tools. 

Team tools, developed for internal use at Tektronix, com¬ 
bined change set tools with configuration management, method 
revision history, and limited merging. Team tools used UNIX 
RCS to implement-check-in, check-out concurrency control. 

Instantiations enhanced and extended the team tools con¬ 
cepts to produce a product called Application Organizer. Dig- 
italk has since acquired Instantiations; the future of former In¬ 
stantiations products is unclear. 

AM/ST is a Coopers & Lybrand product currently available 
for Smalltalk/V only. AM/ST was reviewed in The Smalltalk 
Report, March/April 1992. 
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WHO CAN BENEFIT 

Not every Smalltalk development team needs a groupware 
product as powerful as Envy. In particular, teams of up to 
three people working in the same physical location can get 
by with ad hoc methods. Corporations with multiple two- 
to three-person Smalltalk projects can choose to “roll their 
own,” and develop and maintain groupware based on 
change sets or other file-outs and RCS or SCCS. However, 
these methods break down as the number of team members 
climbs above three or multiple teams need to share com¬ 
pany-wide reusable components. 

Envy really shines for managing large projects with dozens 
of developers. By spreading project responsibility over three 
distinct levels (configuration, application-subapplication, and 
class), managers can control a large project with precision. 

Since subapplications can be nested, project responsibility can 
be further divided to an arbitrary level. 

Envy has special abilities—as well as an established track 
record—in developing embedded systems. Anyone wishing to 
run Smalltalk from anything except a graphical workstation 
should consider Envy the only solution at this time. 

Envy eases parallel development with its merging and 
differencing capability. Very few projects have the luxury of 
never needing to split the development path, perhaps for an 
important demo or due to geographical distance. It is never 
fun merging diverged code, but Envy makes it much easier. 

In short, if you have between roughly 4 and 40 Smalltalk 
developers on a single project, you can benefit from Envy. The 
larger the team, the greater the benefit. As the project leader of 


a successful commercial product using embedded Smalltalk 
and about two dozen developers put it, “We could not have 
done it without Envy!” 

IMPROVEMENT OPPORTUNITIES 

Envy has a solid, industrial-strength feel to it. When something 
unexpected happens, you tend to question yourself, rather 
than Envy. It is truly a product without glaring deficiencies; in 
this case, “improvement opportunities” is not just a eu¬ 
phemism for bug fixes! There are, however, some areas in 
which OTI should concentrate future development. These are 
listed in what we believe to be order of importance. 

Multiple libraries 

While Envy nicely satisfies an unprecedented groupware popu¬ 
lation of up to several dozen developers working in a single li¬ 
brary, it begins to show stress as that number is pushed above 
50 or so, or if the organization wants a multi-library architec¬ 
ture. The needs of a corporate-wide code repository are funda¬ 
mentally different from those of groupware development: ease 
of finding and browsing functional units predominate. While 
Envy has export/import ability between libraries, it would be an 
advantage to be able to access at least a descriptive comment 
about applications in other libraries prior to importing them. 

Renaming and deletion 

Renaming is not supported, so you cannot correct mistakes as 
silly as misspelling an application name. Nor can you delete a 
version, such as one called OBSOLETE! DO NOT USE! (How¬ 
ever, knowing their mistakes will 
continue to embarrass them 
tends to make developers more 
careful!) Envy needs a carefully 
controlled renaming and dele¬ 
tion facility. 


User interface 

Just as climbing a hill reveals the 
mountain behind, user interface 
advances bring out issues that 
other less capable tools have yet 
to conceive. Error avoidance in 
Envy is wonderful, but with it 
comes the responsibility of in¬ 
forming the user what is happen¬ 
ing. New users suffer what we call 
the “gray blues”—wanting des¬ 
perately to perform some menu 
item, but being frustrated because 
the menu item is grayed out (dis¬ 
abled). Context-sensitive help 
would be a desirable addition. 

The need to support so much 
functionality combined with the 
need to support multiple plat- 


Table I. Comparison of groupware environments. 
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80: SmalHaik-80 
2B6: Smalltalk/V-206 
Mac: Smalltalk V/Mac 
PM: Smalltalk V/PM 
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Int: dependencies, detecting conflicts diff: differencing & merging 
share: code sharing, concurrency perf: performance tuning 
hl9t: revision history DLL: link library generalion 

clg: configuration management obj: object storage facility 

doc: documentation support 


feature is not supported 

• fealure is supported 

CD “check with system” available standard with Smalltalk-80 

© "off-line" conflict detection possible after load of conflicting code; no dependency mechanism 
O code sharing and configuration in arbitrary units as decided by developer, with no concurrency control 

• code sharing and configuration in arbitrary units as decided by developer, using Unix RCS 
9 profiling standard with Smalltalk-80 

O Binary Object Storage Sen/ice available for Objectworhs Smalltalk-80 
9 code sharing only at the application level 

9 code sharing of configurations, applications, subapplications, classes, and methods 
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forms creates multiple browsers that differ significantly from 
the Smalltalk vendor-supplied browsers. (Smalltalk/V users 
complain about the “Smalltalk-80-like browsers,” and 
Smalltalk-80 users complain about the “Smalltalk/V-like 
browsers,” but they are both complaining about the same 
browsers!) We can’t offer easy solutions, but keeping closer to 
native browsers would help. 

Peer review 

An important aspect of successful large projects is peer review. 
Since browsing others’ code is so easy, we experimented with 
using Envy for code review, as have others (see “Implementing 
Peer Code Reviews In Smalltalk,” S. Sridhar, The Smalltalk 
Report, July/August 1992 ), by making annotations in place. 
Although it works fairly well with no deliberate support, its 
usefulness could increase if more attention were given to peer 
review. For instance, automatic notification that a review had 
taken place, release controls until review conditions are met, 
and easy feedback to reviewers. 

Documentation 

The Envy manual is accurate and concise, but it is only a ref¬ 
erence manual. The menu item in each pane of each browser 
is described in turn, but there is no user-centered, task-based 


description of the development process. Desperately needed 
are a tutorial and a “cookbook” of “how do I... ” questions 
and answers. 

CONCLUSION 

Smalltalk groupware has had a long struggling childhood. The 
recent availability of several products designed to foster group- 
ware ushered in a gangly, clumsy adolescence, with bits miss¬ 
ing here and bugs hiding there. Envy brings Smalltalk group- 
ware into adulthood, with a complete feature set that fulfills 
today’s groupware needs and the stability expected of a mature 
product. Any team of Smalltalkers working on a common pro¬ 
ject should consider it a leading candidate for solving most 
programming problems. IS 


Jan Steinman and Barbara Yates are partners in Bytesmiths, a tech¬ 
nical services company specializing in object-oriented design, imple¬ 
mentation, and training. Jan has worked with Bytesmiths’ clients to 
create windowless (“headless”) Smalltalk servers using Envy and has 
conducted evaluations of Smalltalk groupware products for clients. 
Barbara teaches Envy training classes for Bytesmiths' clients and has 
assisted numerous teams in conversion to Envy. Together, Jan and 
Barbara have worked with over 80 Envy users and an equal number 
of other Smalltalk groupware environment users. 


Object visibility continued from page 4 

STORE FACTS IN ONE PLACE 

If the same objects are used in a number of methods, hold on 
to this shared information in the object’s class. Class methods 
can be easily designed to yield this default information. It is a 
matter of style whether these objects should be returned from 
class methods or stored in class variables. From an instance’s 
perspective, maintenance of this constant information is an 
appropriate responsibility of its class, regardless of how it is 
accomplished. This eliminates sprinkling the same literal ob¬ 
jects over a number of instance methods. If a literal value 
needs to be modified, the programmer only has to make the 
change in one place. 

Work at reducing the number of objects that a class de¬ 
pends on. Direct reference to any global objects is considered 
harmful by many Smalltalkers. Code with “hard-wired” refer¬ 
ences to other objects is fragile and highly dependent on cor¬ 
rect context being established before it can run. It is difficult to 
reuse code containing global references in another context. To 
be reused, code must either be reworked to remove direct 
global references or scaffolding code must be executed to set 
up the necessary global context, 

LIMIT DEPENDENCIES ON OBJECT STRUCTURE 

Sending messages to self is a valuable implementation tech¬ 
nique for two reasons: It allows programmers to separate de¬ 
tailed steps from main parts of an algorithm, and clearly 
identifies steps in an algorithm that can performed differently 
by a subclass method. 


Just as important, sending accessing messages to self al¬ 
lows code to be insulated from changes in instance variable 
structure. It also allows subclass developers to override those 
accessing methods and provide the necessary information in 
another way. 

DEVELOP A SENSE OF STYLE 

Don’t try to use every language construct when translating 
design-level collaborations into a Smalltalk implementation. 
Current Smalltalk environments have too many ways, for my 
taste, to make objects visible. Teams should develop and stick 
to a style guide that addresses when and how to use particular 
Smalltalk constructs and how to simplify collaboration pat¬ 
terns. Smalltalk programming style is an art and different or¬ 
ganizations quite naturally develop their own styles. It is im¬ 
portant to cultivate a sense of style and create some coding 
guidelines before translating a design into code. El 

Rebecca Wirfs-Brock is Director of Object Technology Services at 
Digitalk, co-author of Designing Object-Oriented Software, and 
program chair for OOPSLA '92. She has 17 years' experience de¬ 
signing, implementing, and managing software products. For the 
last eight years she has focused on object-oriented software, includ¬ 
ing managing the development of Tektronix Color Smalltalk and 
developing, teaching, and lecturing on object-oriented software. 
Comments, further insights, or wild speculations are greatly appre¬ 
ciated by the author. Rebecca can be reached via email at re- 
becca@digitalk.com. Her U.S. mail address is Digitalk, 921 
S. W. Washington, Suite 312, Portland, Oregon 97205. 


October 1992 


11 




UIs 


Greg Hendley and Eric Smith 


Separating the GUI from 
the application, Part 2 


n a recent column (The Smalltalk Report, May 1992) 
we presented an application architecture for separating the 
host-GUI-dependent, presentation-dominant parts of an 
application from the control and semantic portions. In brief, 
the ICM architecture divided interactive applications into 
three primary components: (1) the interface component, re¬ 
sponsible for all aspects of input handling and output presen¬ 
tation that directly involve host GUI features; (2) the control 
layer, the actual intelligence, which carries out commands, 
maintains selections, keeps track of operational validity, etc.; 
and (3) the domain model layer, comprised of all the objects 
representing the information with which the user is working. 

We pointed out several advantages deriving from the use of 
this architecture. Chiefly, ICM applications are very easily 
ported to different platforms. Second, maintenance is eased 
because less volatile sections of code are insulated from more 
volatile ones like the interface. Finally, project maintenance is 
facilitated because the work of application developers and user 
interface specialists is more clearly delineated. 

SCALING UP 

The example code we previously provided implemented a sim¬ 
ple log-on dialog. Although it illustrated the concepts of ICM, 
it was much too simple to be a useful guide to implementing 
an entire application. We will try to make up for this by cover¬ 
ing in some detail a few of the problem areas that arise when 
one first attempts to construct an ICM application. 

GUIDING THE USER 

In any reasonably modern GUI-based application, end users 
are likely to expect menu selections and push buttons that rep¬ 
resent currently invalid operations to be disabled or grayed 
out. Under the ICM model, implementing this behavior in¬ 
volves both the interface and the control components. 

The control part of the application knows what each com¬ 
mand’s prerequisite conditions are. If well designed, it knows 
immediately when any given command has become invalid. 
However, it has no knowledge of what type of user interface el¬ 
ement presents the command as an option to the end user. It is 
possible that the current interface does not present the com¬ 
mand at all. Therefore, the control must pass on to the inter¬ 
face a request to disable whatever interface element, if any, it 
uses to present the command in question. 


For example, assume that the interface has two buttons A 
and B, which represent the control commands cmdA and cmdB, 
respectively. Further assume that when one is pressed, the 
other becomes invalid. In Smalltalk/V PM, this would result in 
the code segment shown below. 

INTERFACE CODE 

The following four methods are instance methods of some 
subclass of ViewManager. 

bcA: aPane 

"The end user pressed button 'A'." 
self control cmdA 

bcB: aPane 

"The end user pressed button 'B'." 
self control cmdB 

disableCmdA "Command A is no longer a valid option." 

(self paneNamed: 'buttonA') 

disable disableCmdB "Command B is no longer a valid option." 
(self paneNamed: 'buttonB') disable 

CONTROL CODE 

The foEowing two methods are instance methods of the class 
that defines the control for the interface. 

cmdA 

"The end user has chosen command A." 

"Do whatever needs done to the domain model here." 

"Command B is no longer an option." 
self userlnterface disableComandB 
cmdB "The end user has chosen command B." 

"Do whatever needs done to the domain model here." 

"Command A is no longer an option." 
self userlnterface disableComandA 

This may seem like quite a few methods just to accomplish a 
simple task. However, there are many advantages to this ap¬ 
proach. First, if the user interface experts later decide that these 
commands should be represented both with buttons and menus, 
only the interface layer would need to change. Each of the disable 
messages would then disable both a button and a menu option. 
The control layer would remain unchanged, unaware of whether 
it is disabling a button, a button and a menu selection, or noth¬ 
ing at aE as a result of sending the message to the user interface. 

Another advantage is that portability has been maintained. 
Should the application be moved to another platform that uses 
a different protocol for disabling user interface elements, then 
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all that must be reimplemented is the interface layer. There is 
no need to comb through the control code looking for proto¬ 
col that depended on the old host GUI. 


terface to accomplish all tasks. The control should send a re¬ 
quest to the user interface to obtain the file name by any means 
and return it. The following two methods illustrate this. 


QUICK POP-UPS 

A small but tempting violation of the separation between the 
platform specific interface and the portable control occurs 
when very small amounts of additional information are re¬ 
quired when carrying out a command. A user may need to ob¬ 
tain a file name or confirm an unexpected or extreme conse¬ 
quence. In that case, the quickest solution is to have the control 
ask the user direcdy. For example: 

cmdA 

"The end user has chosen command A." 

| fileName | 

fileName := Prompter prompt: 'Enter a file name' default: 'file.dat'. 

"Do whatever needs done to the domain model here." 

"Command B is no longer an option." 

self userlnterface disableComandB 

However, this presents several difficulties. By referring directly 
to the class Prompter, platform-specific information is woven into 
the application control and cross platform portability is compro¬ 
mised. Second, if the user interface designers decide to use some 
dialog other than the prompter to obtain file names, then all of 
the control layer must be examined for expressions such as those 
above. Finally, the user interface may have already obtained a file 
name from the user, which was entered in a text entry field in the 
window from which this command was initiated. The control 
code does not and should not know which is the case. 

Although tedious, the best solution is to go to the user in- 


Interface code 
getFileName 

"Sent by the application control. 

Answer a file name or nil if one is unavailable." 

| aFileName | 

afileName := Prompter prompt: 'File:' default: 'FILE.DAT'. 
(aFileName isNil or: [aFileName trimBlanks isEmpty]) 
ifTrue: l* nil]. 

A aFileName trimBlanks 

Control code 
cmdA 

"The end user has chosen command A." 

| aFileName | 

aFileName := self userlnterface getFileName, 

"Do whatever needs done to the domain model here." 

"Command B is no longer an option." 
self userlnterface disableComandB 

This problem worsens when an untoward event discovered 
deep within the domain model—the worst possible place to di¬ 
rectly involve platform-specific classes—requires a confirmer 
or quick dialog. The best solution is to use some kind of excep¬ 
tion handler so that the domain model code can notify the 
control code of the unexpected problem. The application con¬ 
trol assisted by the user interface can help manage the neces¬ 
sary interaction with the end user. 
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SUBORDINATE APPLICATIONS 

It is problematic to mix interface and control code when a sec¬ 
ondary application is opened as a result of a user command, The 
application control recognizes the need to open a new window 
but knowledge about the protocol used to open new windows, 
and the classes that represent them, is interface- and platform- 
specific and should not be included in the control layer. The fol¬ 
lowing method in the control layer violates the ICM architecture. 

cmdBrowseDocument 

"The end user wants to open a browser on the selected document." 
SomeKindOfViewManager new 
openOn: self selectedDocument 

This method causes many of the same difficulties as direct 
reference to class Prompter in the first example above. The de¬ 
cision as to which interface should be used in browsing docu¬ 
ments is moved out of the interface layer. Further, this type of 
reference, from the control layer to a class in the interface layer, 
introduces a complication when porting the application to a 
new platform. When there are no direct references to classes in 
the interface layer in either of the model or control layers, these 
lower two layers can be easily ported to a new platform and a 
new interface layer built on top of them. Methods like the one 
above will introduce unresolved references when ported with¬ 
out the interface layer. These will have to be carefully located 
and resolved when the new interface is constructed. 

Once again, the correct method for handling this sort of 
problem is to pass the problem back to the user interface in a 
manner similar to that used for prompters and confirmers. 
This might result in the following set of methods. 

Interface code 
mcBrowseDocument 

"The end-user has chosen the Browse Document menu option." 
self control cmdBrowseDocument 
rreateDocumentBrowserOn: alile 

"Open a document browser application on the argument." 
self documentBrowserClass new openOn: aFile 
documentBrowserClass 

"Answer the class which defines the preferred document browser 
interface." 

* SomeKindOfViewManager 

Control code 

cmdBrowseDocument 

"The end user has chosen command A." 
self userlnterface 

createDocumentBrowserOn: self selectedDocument 

Again, this might seem an excessive number of messages 
back and forth between the interface and control portions of 


the applications, when one could simply ask the control for 
the selected document and open the correct kind of browser 
from the mcBrowseDocument method. However, as the ap¬ 
plication grows in complexity, the question to browse, or ex¬ 
actly which document to browse, may become quite compli¬ 
cated. Such a decision will involve numerous factors of 
which only the control layer is aware. If the interface has 
short-circuited the control’s responsibilities the command 
will behave incorrectly. 

OTHER PROBLEMS 

As we move up the scale to more sophisticated applications 
with increasingly rich interfaces, nastier problems begin to 
crop up. Handling errors and exceptions can prove especially 
difficult. This can involve sudden invalidation of assumptions 
made by both the interface and control layers. The designer of 
the control must be able to provide the user interface layer 
with notification of any exceptional conditions. The interface 
must be able to present the end user with useful, non-confus¬ 
ing information regarding the situation. This task is especially 
difficult without a good exception-handling mechanism. 

The separation of presentation and control is most difficult 
to maintain when the presentation of the underlying domain 
model to the end user is highly graphical in nature. The most 
convenient implementation in such cases is to design the 
model objects so that they know how to draw themselves on 
some graphic medium. However, this involves burying plat¬ 
form-specific code all the way down in the domain model. 

In our experience, there are several plans of attack for solv¬ 
ing these problems. Not all of them are entirely satisfying, espe¬ 
cially in the case of exception handling. As solutions for these 
situations evolve, we will include them in future columns. IS 

FOR FURTHER READING 

Many of the ideas on which ICM architecture is based, particu¬ 
larly the strong separation of presentation and control, grew 
out of the work of the Dialog Management System group at 
Virginia Tech in the late 1980s. For interested readers the fol¬ 
lowing references are provided: 

Hartson, H. R., Control and communication in user interface man¬ 
agement, Technical Report TR 88-3, Department of Computer Sci¬ 
ence, Virginia Polytechnic Institute and State University. 

Hartson, H., R. Johnson, D. Hix, and R.W. Ehrich, A human- 
computer dialogue management system, Proceedings of 
Interact ’84, London, England: IFIP, Vol. 1, pp. 57-61. 

Yunten, T. and H.R. Hartson, A SUPERvisory methodology and no¬ 
tation for human-computer system development, Advances in Hu¬ 
man-Computer Interaction, H. Rex Hartson, editor, Ablex, 1985. 

Greg Hendley and Eric Smith are both technical staff members at 
Knowledge Systems Corp. Greg Hendley’s OOP experience is in 
Smalltalk/V (DOS), Smalltalk-80 2.5, Objectworks Smalltalk Re¬ 
lease 4, and Smalltalk/V PM. Eric Smith's specialty is custom graphi¬ 
cal user interface using Smalltalk (various dialects) and C. The au¬ 
thors may be contacted at Knowledge Systems Corp, 114 MacKenan 
Drive, Suite 100, Cary, NC 27511, or at CompuServe 72000,1056. 
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MALLTALK IDIOMS 


Collection idioms 


Kent Beck 


C ompared with procedural languages, Smalltalk’s collec¬ 
tions feature is universally regarded as saving the most 
programmer time. The Smalltalk collection hierarchy 
has been widely copied by many, including the popular Na¬ 
tional Institute of Health class library for C++. Along with num¬ 
bers, collections share the distinction of being the most portable 
class among the three major Smalltalk implementations: Ob- 
jectworks\Smalltalk, Smalltalk/V (all flavors), and Enfin/3. 

Once I started talking to my friends about how they use col¬ 
lections I realized I had enough material for two idiom 
columns. Most Smalltalk programmers don’t take full advan¬ 
tage of collection’s features, but the more experienced have a 
bag of tricks (some of which are not obvious at first glance) 
with everything collections have to offer. These programmers 
also know where the traps lie and how to avoid them. 

The remainder of this column takes you through the perils 
of subclassing collections and some of the richness of the col¬ 
lection protocol. Next month we’ll take a brief tour of the most 
common classes, how they are implemented, and when they 
should be used. 

SUBCLASSING COLLECTIONS 

My aesthetic sensibilities are always offended when someone 
creates a subclass of a collection class just because the object 
being created includes a collection. The most obvious example 
of this kind of subclassing is SystemDictionaiy. Until I started 
writing this column I never had a solid engineering explana¬ 
tion for my reaction. Now I think I can explain. 

Unfortunately, subclassing a collection is one of the first 
ideas that comes to mind when you finally understand inheri¬ 
tance. “Oh, I need a polygon. I’ll just subclass OrderedCollec- 
tion. That way I'll get all the adding behavior for free." Lo and 
behold, you can add and remove points from a polygon as 
soon as you define the class. Pretty neat, this Smalltalk stuff. 

It’s not until later that the danger of subclassing a collec¬ 
tion becomes apparent. While there may be a couple of mes¬ 
sages that make perfect sense for your new class, others don’t 
make sense and still others are actually harmful. I confirmed 
this by executing Smalltalk removeKey: #0bject in Objectworks\ 
Smalltalk. Away went class Object, never to return. Smalltalk/V 
Mac asks for confirmation that you want to delete the class, 
but there are other messages just as harmful that no one 
thought to protect. 

By subclassing to gain a collection you have opened up an 


enormous window onto the implementation of your object, vi¬ 
olating its encapsulation and potentially opening it up to 
harmful messages. You can protect your class by overriding the 
offending methods with self shouldNotlmplement. By the time 
you are done, though, you will have a class that gainfully inher¬ 
its a couple of messages while explicitly eliminating a dozen 
others. Even so, you are still vulnerable to someone coming in 
later and adding a method to the superclass that re-exposes 
your subclass. At that point you may as well have inherited 
from Object, added an instance variable for the collection, and 
forwarded the messages you cared about to the collection. 

Back in the olden days, there were few gratuitous subclasses 
of collections. ObjectworkslSmalltalk 4.1 has a half dozen classes 
that inherit from a collection, but don’t otherwise act like collec¬ 
tions. In its defense, UninterpretedBytes (more of which later) is a 
subclass of Object even though it is implemented as a collection 
of numbers. In looking at the V image I see only CompiledMethod 
and Process as collection subclasses that don’t really belong 
(both of these classes are done “right” in OW\ST). 

This perspective on subclassing collections runs counter to 
my usual advice on using inheritance. I am a firm believer that 
inheritance does share implementation, and that’s what it should 
be used for. Rather than read inheritance as “is-a” or “is-kind- 
of,” I read it as “is-implemented-like.” This explanation of in¬ 
heritance is simple for beginners to grasp. It admits a simple 
metric for evaluating inheritance decisions, such as which alter¬ 
native allows the most code sharing. Beginners can flounder for 
months trying to understand “inheritance as abstract specifica¬ 
tion” (a la contracts) or “inheritance as classification” (a la AI). 

I don’t have a glib response to this apparent inconsistency. 
Perhaps the reason collections are not good to inherit from is 
that they have so much behavior at the abstract level. Any sub¬ 
class that isn’t really a new kind of collection is bound to find 
many of those methods inappropriate. Perhaps collections 
have too much behavior and a different factoring of the system 
would yield a more satisfying answer. I do know that subclass¬ 
ing to share implementation usually works, but that collections 
are a notable exception to that rule. 

INDEXABLE SUBCLASS 

While I’m on the subject of subclassing and collections let me 
mention a life-saving facility I have had occasion to use once 
or twice. Let’s say you followed the above advice and made 
your objects subclasses of Object and gave each one an instance 
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variable that holds onto a collection. If the objects are small 
and numerous, the overhead of the additional object (usually 
12 bytes of object header and 4 bytes in the referencing object) 
can add up. If the collection is simple (an Array, for instance) 
you can eliminate the space overhead and improve the locality 
of reference by declaring your object to be an indexable sub¬ 
class. This will add a number of indexed instance variables (the 
number is set at instance creation time in the argument to 
new:) to your object. The conversion will be made much easier 
if you were careful to use collectionAt: and collectionAt:put: to 
access the collection. You can convert: 

collectioiiAt: anlnteger 

''collection at: anlnteger 
to: 

collectionAt: anlnteger 

"self at: anlnteger 

and so on. 

COLLECTION MESSAGES 

Collection implements a variety of behavior for its subclasses. 

It is a triumph of object design that all of that functionality de¬ 
pends only on the existence of three methods in a subclass: do:, 
add:, and remove:ifAbsent:. When implementing new kinds of 
collections, I have been amazed at how quickly I can get going 
just by implementing those three methods. 

ENUMERATION 

Of the behavior implemented in Collection, the enumeration 
methods are the most powerful and hardest to understand. 

The methods are interesting because they are safe to use: None 
of them modify the collection they iterate over. The ones that 
return a collection always allocate a new object for the result. 
I’ll go through the messages, describing what each one does, 
how it is implemented, and when you might want to use it. 

do: 

Do: executes a block for each element in a collection. It oper¬ 
ates strictly through side effects and the results of evaluating 
the block are discarded. Do: must be redefined in each new 
subclass of Collection. 

I went through all senders of do: in the Smalltalk/V Mac 1.2 
image and I couldn’t find any clever idioms. I was surprised at 
how often it was used when one of the other messages would 
have served better. Interestingly, the times do: was used incor¬ 
rectly were primarily when a temporary variable was experi¬ 
encing side effects. If an argument or instance variable was 
changed the use of do: was usually correct. As a positive exam¬ 
ple, look at Collection»prmtOn: 

printOn: aStream 

aStream nextPutAll: self class name. 
aStream nextPut: $(. 

self do: [:each | aStream print: each; space]. 
aStream nextPut: $) 


collect: 

Instead of just executing code for its side effects, perhaps you 
want to transform all the elements of a collection. Collect: exe¬ 
cutes a block for each element, but saves the results and re¬ 
turns them when done. For example, if you want to return the 
absolute values of a collection of numbers you could write: 

absolute: aCollection 

| result | 

result := aCollection species new: aCollection size. 

1 to: aCollection size do: [:each | 

result at: each put: (aCollection at: each) abs]. 

''result 

or you could just write: 

absolute: aCollection 

''aCollection collect: [:each | each abs] 

Collect: and the following messages all have the admirable 
property of removing the need for temporary variables when 
they are used. Methods often shrink by several lines when you 
find a way to use one of the enumeration messages. 

Another big advantage of enumeration messages is that they 
are not sensitive to the kind of collection they operate on. The 
first version of absolute: above assumes that aCollection is in¬ 
dexable by integers (responds to at: and at:put: with an integer 
first argument). If I decided later that the parameter to abso¬ 
lute: could also be a Set, which isn’t indexable, I would have to 
change absolute: to deal with both cases. Since all collections 
respond to collect:, by using it instead I am completely insu¬ 
lated from changes in what kind of Collection is passed in . 

Here is another example where collect: is useful. I often 
make the mistake of converting objects several places within a 
single class. For instance, I might write: 

foo 

strings do: [:each | each asSymbol... ] 

Then I might convert strings to symbols in several other 
loops in other methods. The object in question isn’t taking 
enough responsibility. It should provide the service of convert¬ 
ing its strings to symbols: 

stringsAsSymbols 

''strings collect: [:each | each asSymbol] 

Then I can write: 

foo 

self stringsAsSymbols do: [:each | ...] 

What advantages does this approach provide? First, it’s more 
modular. If I want to stop storing strings and store something 
else (or compute it on the fly) I can just change stringsAsSymbols 
and not have to touch every method where the instance variable 
strings was used. Second, if converting strings to symbols is a 
performance problem I may never see it if it’s buried in half a 
dozen methods. Putting it in a single method makes the perfor¬ 
mance implications clear and provides a simple way of imple¬ 
menting caching should that become necessary. 
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Juanita Ewing 


The dangers of storing objects 


malltalk systems now include the ability to correctly write 
representations of composite objects to disk. Early 
Smalltalk systems could not deal with objects containing 
circular references, so the capability of storing objects was not 
widely used. Now that many kinds of objects can be written, 
other issues have arisen: When is it appropriate to use this 
mechanism? Is this a good way to provide long-term storage of 
objects? Can this capability be overused or misused? 

Object storage was first implemented for Tektronix 
Smalltalk by Steve Vegdahl. 1 In Smalltalk/V this capability is 
called Object Filing. In Objectworks\Smalltalk, this capability 
is implemented by BOSS (Binary Object Streaming Service). 

In all these implementations, an encoded representation of 
an object is written to a file. The representation of the object 
consists of structural information required to recreate the ob¬ 
ject from the data in the file. Objects recreated from the data 
on disk are not the same as the original object. These systems 
do not maintain object identity across read/write operations 
and are therefore not persistent object systems. 

WHAT IS WRITTEN TO DISK? 

When the representation of an object is written to disk, it must 
include all the data necessary to recreate the object. The class 
name is written to designate the class of object to be recreated. 
Each component of the object, numbered slots and instance 
variables, is written. If the component is a reference to another 
object, that object is also written. 

Each implementation has different restrictions on precisely 
which objects are written. The values of global variables such 
as Transcript are not written. Instead, a reference to the vari¬ 
able’s name is stored and when the object is recreated its refer¬ 
ence is bound to the current value of the identifier. 

The representation of an object in these systems is the data 
from the private internal implementation of the object. The 
public interface to an object is not used to recreate the object. 
Private, low-level methods are used instead. 

WHY DO DEVELOPERS WRITE/ 

RECREATE OBJECTS? 

The big advantage of object storage systems is that they permit 
a Smalltalk developer to externalize objects without designing a 
special file format or writing input/output methods. Developers 
might use object storage systems to “transfer” objects from one 
image to another. Other members of a development team 


might need an object that is difficult or time consuming to 
recreate. A prototype might have objects built by hand instead 
of programatically or objects might be created from a data feed. 

Developers sometimes use this ability to “save” objects; they 
want the objects to exist longer than an image. Another use is 
to reduce the size of an application image by building an exter¬ 
nal "database" of stored objects. Then only the objects that are 
actually being used need to be loaded. 

SOPHISTICATED USE 

An application I helped develop had visual components that 
were used off-screen to generate a composite graphic. This 
graphic was stored in an instance variable, but we didn’t want 
it saved when we wrote our objects to disk. It was large and 
took more time to read from disk than to recreate. We needed 
a way to control which components of an object are written. 

Both Object Filer and BOSS have a mechanism to cus¬ 
tomize what is written on a per class basis. 

■ With Object Filer, you implement a method with the selector 
fileOutSunogate:, which returns a surrogate object to be writ¬ 
ten to disk in place of the receiver. The surrogate can be a 
copy of the original object with modified instance variables. 

• With BOSS, you implement a method with the selector rep- 
resentBinaryOn:, which uses other BOSS methods to write 
the representation of the object to a stream. 

Sophisticated use of these systems requires developers to 
write special methods that modify the written representa¬ 
tion of the object, usually by changing the private instance 
state of the stored object. The manner in which these sys¬ 
tems are customized is an indication of the limitations of 
these systems; they manage the storage of an object at the 
structural level. 

DANGERS 

Class definitions are volatile. Instance variables, class variables, 
and pool dictionaries can be added or deleted. Once a change 
is made to the private implementation of an object, such as 
adding an instance variable, the written representation on disk 
is no longer accurate. Because the representation consists of 
private implementation data, the public interface of that object 
is not used to recreate the object. 

Problems arise from: renaming a class; changing represen¬ 
tations; restructuring a class; and refactoring a hierarchy. 
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Most of these systems have mechanisms to handle simple 
variations in an object’s definition. In the case of added and 
deleted instance variables, Object Filer brings up a graphical 
interface that interactively lets you map instance variables on 
disk to the instance variables in your image. This mechanism is 
particularly useful when instance variables have been renamed. 
Object Filer also has a mechanism to support classes that have 
been renamed. 

CHANGING REPRESENTATIONS 

Suppose a composite object consists of a deeply nested tree 
structure. When this object is written to disk, a representation 
of it and all its composite objects is written. Later, the develop¬ 
ers add a cache of recently accessed leaf node to the object. 

This cache, an instance of OrderedCollection, is stored in an ad¬ 
ditional instance variable. The representation of the object on 
disk does not specify a value for the cache instance variable. 
When the object is recreated, it has a nil value for the cache. 

The methods in the composite object must be specially de¬ 
signed to accommodate a value of nil for the cache. Accessing 
methods for the cache must check for nil instead of assuming 
an instance of OrderedCollection and, if necessary, create an in¬ 
stance of OrderedCollection. The developers then save some 
composite objects to disk. 

Later the cache is changed to be an instance of Dictionary. 
Accessing methods are again modified to check not only for 
nil, but for instances of OrderedCollection; if necessary, the 
cache is modified to be an instance of Dictionary. More com¬ 
posite objects are saved to disk. 

What is the situation now? The developers now have repre¬ 
sentations of composite objects with the following variations: 

■ no cache instance variable 

■ cache instance variable bound to instance of OrderedCollection 

■ cache instance variable bound to an instance of Dictionary 

In this example of changing representations, what you really 
have is a mess, with code for backwards compatibility in every 
relevant accessing method. The situation is even worse if you 
don’t use accessing methods and instead directly reference in¬ 
stance variables. You end up with code for backwards compati¬ 
bility in every method that references the instance variable. 

The series of modifications I’ve described is very typical. 

The original definition of a class is rarely correct; definitions 
are changed to accommodate optimizations as described 
above. Functional extensions also require modifications. For 
example, an ellipse class describes an elliptical element with a 
border width and color. It has instance variables to store the 
attributes’ width and color. The developers later add function¬ 
ality for filling the inside area of the ellipse. The class definition 
is modified as another instance variable stores the fill color. 

REFACTORING AND RESTRUCTURING 

The most devastating kind of change is not addition or dele¬ 
tion of instance variables. It is the refactoring and restructuring 
of classes into sets of classes, or the combination of several 


classes into a single class. As developers create an application, 
the design evolves. Responsibilities are redistributed and new 
classes are created. 

Let’s look at a simple example of restructuring. Suppose your 
application records information about people such as their 
name, which is an instance of String. Later you decide a single 
string is not a good representation and you want to model the 
first and last names as two separate entities. If you have stored 
objects with the name represented by an instance of String, you 
must make extensions to the object storage system to: 

■ Read the name 

■ Detect the class 

■ Potentially parse the string to model first and last names 
separately. 

An example of refactoring recently discussed in several pub¬ 
lications is from the Objectworks\Smalltalk user interface li¬ 
brary. The class View has been refactored into a number of 
smaller classes, each with less functionality. Is it possible to 
take a view that has been stored on disk and recreate it in terms 
of the new classes? No doubt it would be easier and less time 
consuming to rewrite the code used to create the view than to 
recreate its equivalent from the object representation on disk. 

ALTERNATIVE 

It is easier to rewrite code to make a view because rewritten 
code uses the public interface to objects. Writing objects to 
disk using the private implementation data is okay for a quick 
transfer, but not a good idea for any long-term needs. 

Object storage systems are very handy for short-term use, 
but because of the dynamic nature of classes, they are unsuit¬ 
able for long-term use. These systems encode structural imple¬ 
mentation rather than the semantics of information. 

Every major Smalltalk application I know of that used an 
object storage system for long-term storage ultimately had to 
be modified to use a less implementation-dependent storage 
format. A good format captures the data without directly spec¬ 
ifying objects and the values of their instance variables. Instead 
it captures relevant data in an object-independent format by 
storing only semantic data. Methods that read the data instan¬ 
tiate new objects by sending public messages. H 
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HE BEST OF comp.lang.Smalltalk 

Some Smalltalk stuff 


he last few editions of this column have dealt with very 
broad 0-0 issues. This time we will discuss three de¬ 
tailed, language-specific issues: Smalltalk text, imple¬ 
menting method pre- and postconditions, and determining a 
source filename during filein. Although we can't solve all of the 
problems, we will get a better understanding of them. 

FORMATTING 

There are programs available for formatting or “pretty¬ 
printing” most computer languages. The simpler ones, based 
on recognizing simple syntactic cues, often break when con¬ 
fronted with complex syntax or strings with escape sequences. 
The more sophisticated a formatter gets, the closer it comes to 
actually parsing the language. 

ParcPlace Smalltalk has a built-in formatter. Because it is 
part of an integrated environment, it can directly use the 
parser to do its formatting. This is not necessarily good, as 
William Eric Voss (voss@cs.uiuc.edu) describes: 

I generally love the ‘format’ item on the CodeView 
menu... .However, occasionally I encounter a long method 
with more than a dozen lines. I would like to place inline 
comments in such methods. However, if I then invoke ‘for¬ 
mat’ my comments jump a line or more, often becoming 
very misleading as a result. 

Could someone clearly explain why this happens?... Does 
anyone have a workaround (other than don’t use ‘format’)? 

Danny Epstein (dje@scs.carleton.ca) explains: 

The ‘format’ command works by parsing the source 
code and then pretty-printing the parse tree. When a 
comment is read in (by the scanner, if I remember cor¬ 
rectly), it is attached to the ‘current’ parse node. This 
isn’t really what is desired since there are several places 
in the source code where a comment could go, all of 
which would get associated with the same parse node. 
Multiple comments are handled, but their positions are 
not stored. A better technique would be to associate a 
comment with the parse node whose code immediately 
precedes it. If there are several, then the largest one 
should be used. For example: 

x := 1 + 2. "comment foT statement" 
x := 1 + 2 “comment for 

Note that the second comment is not bound to the 2. The 
pretty printer then outputs comments after the code. The 
only exception is that comments are never associated with 


the entire method. What we call method comments are really 
comments on the method header (since they appear after it). 
You could change the parser as described above. I can’t 
think of a quick hack to fix the problem. 

All this being said, I myself never use ‘format’ because I 
don’t like its formatting rules. C’est la vie. A good format¬ 
ter should have lots of user options so it can get close to 
what the user would do manually. 

Unfortunately, this explanation doesn’t provide a solution 
or workaround, only an understanding of the source of the 
problem. Anybody care to undertake the job of writing a really 
good formatter for Smalltalk? 

ASSERTIONS 

One of the nice things about Smalltalk is its flexibility, its abil¬ 
ity to implement interesting features of other languages. One 
worthwhile feature might be assertions, which allow you to 
specify the behavior of code in a way that can be checked (as 
opposed to comments). Assertions are a staple of formal meth¬ 
ods and an important part of the Eiffel language. It’s easy to do 
a trivial version of assertions. We define an Object method: 
assert: aZeroAigumentBlock 

self asseitionChedringlsOn ifTrue: [ 
aZeroArgumentBlock value iffalse: [ 
self error: 'assertion failed 1 ]]. 

We check some sort of state variable to indicate if assertions 
are active; if so, we evaluate the block. An example of using this 
method is: 

someMethod: aParameter 

self doSomeWork: aParameter; 

assert: [alreadyProcessedlist includes: aParameter]. 

"self. 

This verifies that the parameter has been added to the list of 
processed items. Although this is useful and provides about the 
same level of functionality as the C “assert” macro, it’s not 
nearly up to the level of Eiffel assertions, which are built into the 
language. Eiffel supports assertions as method preconditions, 
postconditions, and class invariants. A precondition specifies the 
necessary conditions before a method can execute and is 
checked just before execution. A postcondition specifies what 
should always be true after the method has finished executing 
and is checked just after method execution. A class invariant 
specifies something that should always be true for an instance of 
a class and is checked every time an operation modifies an in¬ 
stance. We’d like to be able to use these much more useful asser¬ 
tions in Smalltalk. Bernhard Humm (humm@cs.uow.edu.au) 
specifies the requirements in more detail: 
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I would like to introduce the concept of ASSERTIONS 
(e.g., [Meyer 90]) into Smalltalk pieces of code to be exe¬ 
cuted before (precondition) and after (postcondition) exe¬ 
cution of the method body. I would have thought extend¬ 
ing Smalltalk with this feature would be easy. I defined the 
following requirements: 

■ The definition of the method body is done in exactly the 
same way as without using assertions. The semantics of ex¬ 
ecution does not change (including the semantics of a re¬ 
turn statement and a missing return statement). 

■ Pre- and postconditions are defined in the method defini¬ 
tion (not in separate methods). 

■ Invoking the method with the assertions does not differ 
from invoking the method without assertions (this ensures 
that you can add assertions to previously defined messages 
without changing other parts of the system). 

Example: 
plus: aNumber 
"self 

precondition: [aNumber isOffype: Integer] 
body: [ A aNumber + self] 
postcondition: [:res | res isOfiype Integer] 

However, the implementation of precondition: body: post¬ 
condition: seems to be difficult. The problem is the seman¬ 
tics of the return statement (which, when encountered, im¬ 
mediately exits the method invocation without any chance 
to perform the postcondition). 

This clearly defines the previously described problem with the 


■ The best of comp.lang 

assertion mechanism. The return statement apparently makes it 
impossible to be sure assertions will be checked anywhere except 
the beginning of the method, and even this cannot be guaranteed 
if there is a return statement in the assertion block. 

Blocks 

The reason for the difficulty is the peculiar nature of blocks in 
Smalltalk. Blocks are similar, but not quite identical, to func¬ 
tions (in a language where functions are first-class). Blocks can 
have local variables (at least in recent ParcPlace implementa¬ 
tions); they can be assigned, passed as parameters, and evalu¬ 
ated. They are also lexically scoped: a block “inherits” the 
scope of the method by which it was created. 

Blocks and functions differ in the return statement. A re¬ 
turn exits from a function but exits from the method in which 
the block was defined. This is necessary because of how 
Smalltalk uses blocks, but it can cause difficulties and confu¬ 
sion. Consider the following collection method: 
detect: aBlock 

self do: [:eachltem | 

(aBlock value: eachltem) 
ifTiue: ["eachltem]]. 

In this case, we really want the return to exit from the de¬ 
tect: method rather than either of the enclosing blocks. If state¬ 
ments are written using blocks, a return that only exits the lo¬ 
cal block would make it impossible to write the common 
Smalltalk statement: 

someCondition 

ifTrue: [''something] 
iffalse: ["somethingElse]. 

On the other hand, consider the case of a complicated sort 
block: 

someMethod 

| sortBlock collection | 
sortBlock := [:thingl :thing2 | 

thing 1 conditionl ifTrue: ["true], 
thingl condition2 ifTrue: ["true). 

(thingl conditdon3 and: [thing2 conditionl]) 
ifTrue: [ A true]. 

"false], 

collection := SortedCollection sortBlock: sortBlock. 

"collection. 

If blocks were really functions this would return a SortedCollec¬ 
tion using this peculiar sorting condition. Instead, it returns a col¬ 
lection that reports an error as soon as an item is inserted. Specifi¬ 
cally, someMethod returns the local collection. If we then say: 
collection add: anObject. 

the same invocation of someMethod tries to return again, 
causing a very confusing walkback. The very idea of a function 
invocation returning twice is bizarre. 

Different semantics don’t cause a serious problem in this 
case, which is easy to work around. We can implement a 
method to do the comparison, or it can be written using nested 
ifs or a case statement. Complex code inside blocks present one 
reason I find the lack of any kind of case statement in Smalltalk 
irritating enough to write my own. These semantics cause 
more difficulty for assertions. 
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Back to assertions 

One way of handling the problem would be to define two sepa¬ 
rate kinds of return operations, one restricted to blocks. This 
would do the job but is a lot of work, a substantial change to 
the language, and hardly fits the description of Smalltalk as be¬ 
ing flexible enough to easily implement language features. 

Fortunately, at least in ParcPlace Smalltalk, there is an 
easier way, which Mario Wolczko (mario@cs.man.ac.uk) 
describes: 

In Smalltalk-80, since version 2.4, you can associate an ‘un¬ 
wind’ block with a method to deal with exactly this situation. 
Example: 

[f :■ (Filename named: 'foo') writeStream. 
self doSomethingWith: f] 
valueNowOrOnUnwindDo: [f close]. 

Even if the code invoked by doSomethingWith: causes a re¬ 
turn ‘over’ this method, the ‘unwind’ block (argument to 
valueNowOrOnUnwindDo:) will be executed, closing the file 
cleanly. 

Your method will look something like: 

precondition: preBlock body: bodyBlock postcondition: 
postBlock 

self check: preBlock. 

A bodyBlockvalueNowOrUnwindDo: [self check: postBlock] 

This seems an ideal solution to a very difficult problem. My 
only question is whether there might be a substantial perfor¬ 
mance cost associated with using an unwind block. 

FINDING FILENAMES 

Another question from William Eric Voss (voss@cs.uiuc.edu): 

When you have a multiple file goodies package, it is very 
common to have a file which looks something like: 

| baseDir | 

"Change the next line then fileln this file." 
baseDir := Filename named: 

'/where/this/ stuff/lives'. 

(baseDir construct: 'filel.sf) fileln. 

(baseDir construct: 'file2.st') fileln. 

...etc... 

‘Less portable implementations use stringl, string2 instead 
of the construct: method.’ 

It seems like there should be some way to do away with 
that annoying ‘change this’ line. (AFilename requestFile- 
name: line is just as bad.) 

There should be a method something like 

baseDir := Filename whatlAmBeingFiledlnFrom. 
Something like the C and Shell script standard of setting ARG [0] to 
the program’s filename, but for fileins. 

Does such a method exist somewhere that 1 am unaware of? 
ifFalse: [ParcPlace please consider this an enhancement 
request]. 

I’m afraid this is also one of those questions without an easy 
answer, but Jan Steinman (steinman@is.morgan.com) has 
some good starting points: 
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A neat hack that I added to Tek Smalltalk some years ago 
was to give the fileln a receiver, which is quite easy to de¬ 
fine as the Stream being filed in from. Then, it becomes a 
simple matter of sending messages to ‘self in the fileln, 
such as: 

(self directory oldFileNamed: 'nextFfie') fileln! 
(That’s an old Tek Smalltalk idiom—kids, don’t try this at 
home!) I had used this to provide a dependency mecha¬ 
nism, whereby a fileln could determine if what it needed 
was present, and if not, it could go load it! 

Now I’m using Envy, and therefore have no need of such 
things, and have not tried to do them in PPS Smalltalk. As 
a start, look at PeekableStream»fileIn and try changing: 

Object evaluatorClass 
evaluate: self nextChunk logged:... 
to: 

Object evaluatorClass 

evaluate: self nextChunk for: self logged: ... 

This will cause ‘self in the fileln to refer to the Stream be¬ 
ing read. Then you can do things like: 

[ baseDir | 

baseDir :■ FileDirectory fullPathFor: 
self ioConnection name! 

in your fileln code. Be careful of‘self if the fileln code might 
not be a file, since ‘self could be an instance of Peekable- 
Stream (which has no ioConnection), or ioConnection might 
be an instance of ExtemalConnection (which has no name). 
Disclaimer: I have not done any of this in PPS Smalltalk! 
Browse the Stream classes and FileConnection to discover 
other neat things you might do with this mode. Happy 
hacking! EH 


Alan Knight is a researcher in the Department of Mechanical and 
Aerospace Engineering at Carleton University, Ottawa, Canada, 

K1S 5B6. He currently works in ParcPlace Smalltalk on problems re¬ 
lating to finite element analysis, and has worked in most Smalltalk 
dialects at one time or another. He can be reached at +1 613 788 
2600 x5783, or by e-mail at knight@mrco.carleton.ca. 
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THE TOP NAME 
IN TRAINING IS ON 
THE BOTTOM 
OF THE BOX. 


Where can you find the 
best in object-oriented training? 

The same place you found 
the best in object-oriented 
products. At Digitalk, the 
creator of SmalltalkA/. 

Whether you're launching 
a pilot project, modernizing 
legacy code, or developing a 
large scale application, nobody 
else can contribute such inside 
expertise. Training, design, 
consulting, prototyping, 
mentoring, custom engineer¬ 
ing, and project planning. For 
Windows, OS/2 or Macintosh. 
Digitalk does it all. 


ONE-STOP SHOPPING. 


Only Digitalk offers you a 
complete solution. Including 
award-winning products, proven 
training and our arsenal of 
consulting services. 

Which you can benefit 
from on-site, or at our 
training facilities in Oregon. 
Either way, you'll learn from a 










staff that literally wrote the 
book on object-oriented 
design (the internationally 
respected “Designing Object 
Oriented Software"). 

We know objects and 
SmalltalkA/inside out, because 
we've been developing real- 
world applications for years. 

The result? You’ll absorb 
the tips, techniques and 
strategies that immediately 
boost your productivity. You’ll 


100% PURE OBJECT TRAINING. 


reduce your learning curve, 
and you’ll meet or exceed 
your project expectations. All 
in a time frame you may now 
think impossible. 


IMMEDIATE RESULTS. 


Digitalk’s training gives 
you practical information and 
techniques you can put to 
work immediately on your 
project. Just ask our clients 
like IBM, Bank of America, 
Progressive Insurance, 
Puget Power & Light, U.S. 
Sprint, plus many others. 
And Digitalk is one of only 
eight companies in IBM’s 
International Alliance for 
AD/Cycle — IBM’s software 
development strategy for the 
1990’s. Fora full description 
and schedule of classes, call 
(800)888-6892x411 . 

Let the people who put 
the power in Smalltalk/V, help 
you get the most power out of it. 


DIGITALK 





